Plugging in and into code bubbles: the code bubbles architecture

Code Bubbles is an attempt to redefine the user interface for an integrated programming environment. As it represents a whole new user interface, implementing it as a plug-in is inherently difficult. We get around this difficulty by combining two different plug-in architectures, a standard one based on registrations and callbacks, and a message-based one that puts the plug-in at arm’s length and defines a narrower two-way interface. This paper describes both how we have implemented Code Bubbles as a plug-in to Eclipse and how Code Bubbles itself is implemented as a set of plug-ins representing the different aspects of the environment, using both traditional and message-based plug-in architectures as appropriate. It also shows how the resultant architecture is flexible enough to support collaboration, different back ends, and a cloud-based environment. 1. The Architecture of Programming Environments For over 25 years, integrated programming environments have been built as a series of plug-ins [38]. Today’s commercial and standard environments, Visual Studio, Eclipse, and NetBeans, all accommodate new tools as plug-ins. Thus, when we started to develop a new environment framework we naturally wanted to develop it as a plug-in. Plug-ins have been widely used in programming environments and are common in software including web browsers, document systems, development environments, computer algebra systems, web servers, and more [9,15,24,30,36,42]. Developing programming tools as plug-ins has many advantages. The principal one is that the tool can make use of the overall framework and previous tools. Framework support can include user interfaces, error interfaces, editor support, and access to precomputed program analysis in the form of annotated abstract syntax trees, symbol tables, etc. This approach tends to ensure that the tools conform to the standards of the rest of the environment, for example, by having a common user interface, common means for accessing the tool, and common means for displaying errors and results. It can greatly simplify the plug-ins since each tool does not have to do its own analysis to keep its internal data structures up to date as the programmer edits the code. At the same time, there are potential disadvantages to developing new tools as plug-ins. A tool designed as a plug-in might be limited to a particular programming environment; it is generally difficult to use an Eclipse Java plug-in with NetBeans for Java for example. Plug-in tools need to conform to the user interface standards of the environment; for example, tools in Eclipse generally need to use SWT as their graphics package. Unusual tools might find the environment was not designed to accommodate them as plug-ins and their implementations can thus be very difficult. Tool implementations may interfere with other features of the environment, for example a tool that does run time monitoring and instrumentation may interfere with debugging. Tools might have resource demands that exceed those of the underlying environment, for example requiring considerable memory or computation. Tools also have to be debugged, and crashing one’s programming environment can leave the source and target system in an unstable state. There are multiple ways that plug-ins can be implemented in an environment. Most of today’s environments use a modified “toaster” model [10]. Here the plug-in is designed to fit against a standardized backbone which includes the program interface for initializing and running the tool, access to standard data structures such as the project, source files, syntax trees, semantic information, and ways of adding buttons, panels, and other user interface components to the standard environmental interface. This is augmented with an event register-callback mechanism that the plug-in can use to act based on events in the environment, for example, when an error is found, when the program reaches a breakpoint, when a file is saved, or when the user clicks on a button. Eclipse is a good example of such an environment [25]. Eclipse uses the OSGI dynamic component model [1] to organize its plug-ins. This model provides extension points that plug-ins can implement or provide. Extension points act as callbacks and call-ins to the plug-in. Plug-ins can also access other plug-ins directly. Each plug-in consists of a file that contains the executable code, a description of its dependencies (so the direct calls can be bound correctly), the extension points that it uses, and any new extension points that it provides. The OSGI implementation handles automatic loading, binding, and access to the extension points. Extension points are provided for most user interface interactions (e.g. buttons, windows, dialogs, panels). Extension points are also provided for features such as quick fix and refactorings. The base Eclipse implementation itself is minimal, and most of its features, including items such as basic Java support, are implemented using plug-ins. Eclipse generally has been a very successful example of a plug-in architecture. The basic framework has served as an IDE for a variety of languages including Java, Python, and C/C++ and for different forms of web development. The framework is also widely used in research projects, providing a way of experimenting with new tools, many of which, like Mylyn [18], eventually become part of the environment. Other items, such as IBM’s Jazz (Rational Team Concert), are plug-ins to some extent, but require a significant amount of external code and effort. Integrating with tools such as SVN requires adding multiple plug-ins. While the toaster-model of plug-ins is the most common, it is not the only approach to developing an extensible programming environment. We used an alternative approach using a message bus in the FIELD environment [31]. A message server ran as a separate process and all tool interaction was done via messages sent on sockets to this server. Each tool was run in its own process with a small wrapper that interfaced with the message server rather than running all the tools as plug-ins in a common process. Tools registered patterns describing the messages they were interested in with the message server. Tools then sent messages to the message server. These were either messages designed as commands for other tools, or messages that might be informative to other tools. The message server in turn would forward the messages to all clients that had registered matching patterns. Messages could have associated replies, which would then be returned to the original sender through the message server. Messages in this context were used both for notifying all tools of interesting events such as a breakpoint being reached, and to create flexible, standardized interfaces to the various tools. For example, the editor could request or send information to the debugger without knowing anything about which debugger or its particular implementation. Message passing has become a common method of interprocess communication and is used in a wide variety of areas including parallel computing, distributed computing, object oriented programming, and event notification systems. For parallel and distributed computing systems where processing units do not have access to shared memory, messaging passing is commonly used to facilitate inter-process communication [21]. MPI is a widely used message passing communications language for parallel computing [14]. Message passing is important for microkernel architectures, which are composed of many small programs that rely on high speed inter-process communication [20]. Message passing is also used to allow components in plug-in architectures to communicate [40,43]. Some programming languages have special support for message passing. APRIL is a programming language for building distributed applications that uses message passing for inter-process communication [22]. In APRIL, processes subscribe to messages by listing a set of patterns they are willing to accept, similar to the techniques used in FIELD. While a message-based interface provides less information and facilities to the individual tools than a toaster-type interface, the looser coupling has the advantage of being more flexible and allowing more tool independence.